You
have seen the fundamental DR patterns you will be targeting and also
recognize how to identify the highest priority applications and their
tightly coupled components for DR. Now let’s look again at the specific
Microsoft options available to implement various DR solutions. These
options include data replication, log shipping, database mirroring, and
database snapshots.
Data Replication
One of the strongest and
more stable Microsoft options that can be leveraged for disaster
recovery is data replication. Not all variations of data replication
fit this bill, though. In particular, the central publisher using
either continuous or very frequently scheduled distribution is very
good for creating a hot spare of a SQL Server database across almost
any geographical distance, as shown in Figure 1.
The primary site is the only one actively processing transactions
(updates, inserts, deletes) in this configuration, with all
transactions being replicated to the subscriber, usually in a
continuous replication mode. The
subscriber at the DR site is as up-to-date as the last distributed
(replicated) transaction from the publisher—usually near real-time. The
subscriber can
be used for a read-only type of processing if controlled properly and
that read-only access does not hinder the replication processing and
put your DR pattern at risk.
The newer peer-to-peer
replication option provides a viable active/active capability that
keeps both primaries in sync as transactions flow into each server’s
database, as shown in Figure 2.
Both sites contain a full copy of the database, with transactions being
consumed and then replicated simultaneously between them.
Log Shipping
As you can see in Figure 3,
log shipping is readily usable for the active/passive DR pattern. You
must understand that log shipping is only as good as the last
successful transaction log shipment. Frequency of these log ships is
critical in the RTO and RPO aspects of DR. This is really not a
real-time solution. Even if you are using continuous log shipping mode,
there is a lag of some duration due to the file movement and log
application on the destination.
Remember,
log shipping is destined to be deprecated by Microsoft (unofficially
announced). So it is perhaps not a good idea to start planning a future
DR implementation that will go away.
Database Mirroring and Snapshots
Database mirroring is
rapidly becoming the new, viable DR option from Microsoft. In either a
high-availability mode (synchronous) or performance mode
(asynchronous), this capability can help minimize data loss and time to
recover (RPO and RTO). As you can see in Figure 4,
database mirroring can be used across any reasonable network connection
that may exist from one site to another. It effectively creates a
mirror image that is completely intact for failover purposes if a site
is lost. It is viable in both an active/passive pattern and in an
active/active pattern (where a database snapshot is created from the
unavailable mirror database and is used for active reporting).
Note
It is likely Microsoft will rapidly enhance database mirroring to support all DR patterns over time.
